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Post LAC 2008 state 


Desirable goals from LAC 2008 ’The Future of JACK meeting” 

o Startup & configuration : a bit of work 
o NetJack : yes in progress 
o Desktop integration : yes in progress 
o Internal design : yes in progress 
o Client programming and API : yes in progress 
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Not anticiped 

o External contacts and developments 
o Solaris version with new ’’profiling” tools 












What has been done? 


2008 Developments 

o Internal design : code restructuration (Grame) 
o Server control API : (Nedko Arnaudov, Grame) 

o D-Bus based server control (Nedko Arnaudov, Juuso 
Alasuutari, Grame) 
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Other 

o External contacts : RTL, CopperLan, Native Instruments 
o OSX and Windows specific tools 
o Future developments (MIDI, ’’pipelining”, control...)? 













Internal design 


Goals 

o Cleanly separate server and client side services 
o Define a server control API 
o Improve server internal clients (example of use in 
NetJack2) 





Server and client side libraries 


Server side 

o libjackserver : JACK API (opens client as ’’internal” in the 
server...) + control API 
o used by backends and internal clients 
o used by ’’jackd” and new ’’jackdbus” control applications 
o allows an application to embed the server in it’s process 
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o libjackserver : JACK API (opens client as ’’internal” in the 
server...) + control API 
o used by backends and internal clients 
o used by ’’jackd” and new ’’jackdbus” control applications 
o allows an application to embed the server in it’s process 

Client side 

o libjack : JACK API (opens client in separated processes 
using IPC...) 

o used by client applications 













Control API 


Objectives 

o dynamically retrieve server control parameters, backend 
and internal clients parameters, get/set their values 

o create/destroy the server 
o start/stop the server with a given backend 
o load/unload internal clients 
o now used by "jackd” 









Internal clients 


How are they controled and loaded? 

o using the ’’old” way (with jackJoad -i ’’parameters” and 
jackjjnload) 

o using the new control API way : jackctLserverJoadJnternal 
and jackctl_server_unload_internal 





D-Bus description 


What is D-Bus? 

o a simple inter-process communication (IPC) system 
o programs register for offering services to others 
o clients look up which services are available 






D-Bus server control access 


D-Bus server control access 
o jackdbus executable to start D-Bus service 

o behaves as an interface between D-Bus system and the 
JACK server, to use JACK control API with D-Bus 

o server autostart done by libjack using control D-Bus 
interface 








D-Bus server control access 


Exported interfaces 

o jackdbus controller object export several interfaces 
o configure the server (parameters access) 
o control the server (start/stop) 

o ’’patchbay”: improved graph state access (connections, 
notification of changes...) 

o jack.control python control tool 
o better presented in Juuso presentation on LASH 




NetJack2 


Design 

o simplify the usability model 
o redesign for easier multi-platform support 
o currently developed for LAN only 







NetJack2 


Design 

o simplify the usability model 
o redesign for easier multi-platform support 
q currently developed for LAN only 

Components 

o keep the master/slaves model 
9 netmanager (master) and jack_net bakend (slave) 
o ’’adapters”: audioadapter and netadapter 







Netmanager 


Life cycle 

o loaded as an internal client 
o waiting for slaves on a multi-cast address 
o create ’’proxy” internal clients for each slave, with 
requested number of in/out audio and MIDI ports 

o ’’proxy” ’’automatically” appear and disappear when slaves 
come and go 










Net backend 


Life cycle 

o appears as ’’available”, server is running in ’’dummy” mode 
(clients can connect...) 

o connecting to master, describes it’s parameters : in/out 
ports... 

o retrieve sample rate and buffer size from the master 
o starts processing 

o if master disappear, go back in ’’dummy” mode 







Example of setup 
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Data streams 


Data stream 
o audio and MIDI 

o latency control (using ’’fast”, ’’normal”, ’’slow” transmission 
modes...) 

o number of in/out audio/MIDI ports, address, UDP port, 
MTU parameters 







Adapters 


Adapting network to audio interface 

o aims at ’’adapting” (sample rate, buffer size, clock drift...) a 
network stream on an audio interface 

o audioadapter : adapts a slave synched on Net backend on 
it’s audio card (generalisation of alsaJn/out) 

o a version on each plafform (Linux/ALSA, OSX/CoreAudio, 
Windows/PortAudio, Solaris/OSS) 

o netadapter : adapts the network stream on a slave running 
an audio backend 






Adapters 
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Adapters 


How does they work? 

o ’’produces/consumer” model using an intermediate ring 
buffer 

o resampling if needed (using libsamplerate) 

o resampling ratio dynamically adjusted using Torben Hohn 
PI controler (JACK1) 









’’Profiling” tools 


Objectives 

o record timing informations when graph is running 
o timing of backend, signal, wake-up, end date of each client 
o compute scheduling latency and client duration 
o generate log files and visualization scripts for GnuPlot 










Audio driver interrupt 


Duration between successives audio interrupts 

o 64 frames, 48 kHz, regular interrupt 






























Audio driver interrupt 


Duration between successives audio interrupts 

o 64 frames, 44.1 kHz, non regular interrupt 







































Driver end date 


Duration between start and end of cycle at driver level 
o 64 frames, 48 kHz, asynchronous mode 
































Driver end date 


Duration between start and end of cycle at driver level 
o 64 frames, 48 kHz, synchronous mode 




























Clients end date 



End date of all clients 

o here at 64 frames, 48 kHz 

Clients end date 





















Clients scheduling latency 



Duration between signal date and actual wake-up date 
o here at 64 frames, 48 kHz 

Clients scheduling 






































Clients duration 


Duration between wake-up date and end date 
o here at 64 frames, 48 kHz 


Clients duration 
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Adapters profiling : resample ratio 


Server running with the ’’dummy” driver and audio adapter 



























Adapters profiling : position in ringbuffer 




























Solaris version 


Reviewer comment: why on earth would anybody seriously 
consider Solaris for pro-audio work? 

o well, this version was funded by french radio RTL... 

o OSS RME MADI 64 in/out driver developed by Hannu 
Savolainen 

o actually not so bad (could be caracterized using the 
profiling tools) : below 80 usee max scheduling latency 
using CPU sets on a highly loaded 4 cores 2 Ghz Dell 
machine 

o so good enough for RTL needs 









External contacts 


RTL french radio 

o Developing their entirely ’’digital” radio using JACK2 on 
Solaris with a RME MADI 64 in/out card 

o Profiling tools to help caracterize real-time behaviour of the 
system 
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CopperLan 

o A ’’complete solution for networking all equipment in the 
domains of pro-audio and music” recently presented at 
Frankfurt MusikMesse 

o Klavis Technologies implemented a JACK / CopperLan 
bridge prototype on OSX 

Native Instruments 

o Future line of Nl product using JACK API natively on OSX 
and Windows 













Specific developments on OSX and Windows 


JackOSX package 

o integrates JACK with CoreAudio (JackRouter CoreAudio 
device, JackAU audio unit, JackVST VST plugin...) 

o based on Jackdmp/JACK2 starting early 2008 (version 
0.75) 

o 5 versions released in 2008 
o 200 download/day, 1100 users on Yahoo Group 
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JackOSX package 

o integrates JACK with CoreAudio (JackRouter CoreAudio 
device, JackAU audio unit, JackVST VST plugin...) 

o based on Jackdmp/JACK2 starting early 2008 (version 
0.75) 

o 5 versions released in 2008 
o 200 download/day, 1100 users on Yahoo Group 

Windows 

o integrates JACK with Windows ASIO (JackRouter ASIO 
device) 

o some improvements done in QjackCtl 
o clean installer (Romain Moret in 2008) 










Contributions (1) 


A lot in 2008 

o Recent code from JACK1 : Paul Davis, Florian Faber, 
Torben Hohn... 

o Nedko Arnaudov, Juuso Alasuutari for D-Bus and waf 
scripts 

o Romain Moret for NetJack2 

o Tim Blechmann : code cleanup/optimization, SSE code... 
o Marc-Olivier Barre for D-Bus and ’’now dead” scons 
scripts... 













Contributions (2) 


Michael Voigt: JACK2 on L4/DROPS research project 

o L4 : micro-kernel design and DROPS: Dresden Real-Time 
Operating System Project 

o code source restructuration for easier later port 

o timing benchmark : less than 10 usee scheduling latency 
(+/- 1 usee) (RT Linux is 40 usee +/- 20 usee on same 
machine) 

o future : has to be used with L4/Linux to run JACK 
applications for Linux on DROPS 













The future : what is still needed for 2.0 version? 


MIDI bridge on all supported platforms (in progress) 

o JACK MIDI bridge with native API on each plaform 
(CoreMIDI on OSX, WinMME on Windows, ALSA MIDI 
(seq/raw)) 

o proposal to use the already existing Master / slave model 
in backend 

o allows to activate the MIDI backend independently from the 
audio backend 
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The future : what is still needed for 2.0 version? 


MIDI bridge on all supported platforms (in progress) 

o JACK MIDI bridge with native API on each plaform 
(CoreMIDI on OSX, WinMME on Windows, ALSA MIDI 
(seq/raw)) 

o proposal to use the already existing Master / slave model 
in backend 

o allows to activate the MIDI backend independently from the 
audio backend 

NetJack 

o both versions should be merged 

Missing port latency API? 

o Paul and Fons proposal? 











The future : what is still needed for 2.0 version? (2) 


Audio device reservation scheme 

o smoother collaboration with PulseAudio 

o use Lennart Poettering proposed D-Bus based reservation 
API 

o allows JACK ALSA backend to take precedence over 
PulseAudio (unconditionnal reservation) 
o available and to be tested since JACK 1.9.2 version 



The future : various ideas 


Multi-backend model 

o Master / slave model for audio backend... 
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More control frontend 
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The future : various ideas 


Multi-backend model 

o Master / slave model for audio backend... 

More control frontend 

o OSC (network control: server start/stop, connection 
state...) 

’’libjacknet” idea 

o publish the NetJack API (master, slave, adapter) in a 
separated ’’libjacknet” library 

o allows audio components to access NetJack without the 
need of a JACK server 

o successfully tested on iPhone simulator (master or slave) 












The future : pipelining version (1) 


What is it for? 

o allows to better use multi-cores machines with ’’sequential” 
graphs 

o general principle : executes the graph with a buffer size of 
D/N (D : driver buffer size, N : divisor) 



The future : pipelining version (2) 


One example 


Dividing the buffer by 4 
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• • 

Two cores running A and B 







































The future : pipelining version (3) 


o divisor can be dynamically changed, and causes a 
’’buffer-size change” notification 

o client can chose *not* to be pipelined : so hybrid graphs 
can be run 

o available on a separated ’’pipelining” branch on SVN 

o testing in real word situations welcome! (Ardour 2.8 is 
ready for that...) 



